\section{A motivating example}\label{sec:jtl}

\vspace{-0.2cm}

\noindent
It is more the rule than the exception that uncertainty is part of almost any aspects of software development~\cite{SCRS05}. This is also valid for model transformation design and implementation. In particular, in this section we describe how lack of information at design-time can lead to non-deterministic transformations which generates uncertainty in the solution because some  mapping between elements in models may be ambiguous.

To better understand the problem and the difficulties it poses, we firstly introduce a well-known application scenario and secondly provide an implementation with JTL highlighting its  intrinsic non-determinism. 

\subsubsection{Scenario.}

\vspace{-0.3cm}

\begin{figure*}[htbp]
  \center
   \vspace{-0.4cm}
   \includegraphics[scale=0.3]{figures/roundTrip_caso3-2.jpg}ù
   \vspace{-0.5cm}
   \caption{Collapse/expand state diagrams in a round-trip process}
   \vspace{-0.5cm}
   \label{fig:stateMachines}
\end{figure*}
% 
Let us consider a typical round-trip problem
%~\cite{HLR08} 
based on the \emph{Collapse/Expand State Diagrams} benchmark~\cite{CFHLST09}.  In particular, starting from a hierarchical state diagram (involving some nesting) as the one reported in Fig. \ref{fig:stateMachines}(a), the bidirectional transformation yields a flat state machine as provided in Fig. \ref{fig:stateMachines}(b). A fundamental requirement of the transformation prescribes that manual modifications on the target model must be back propagated to the source model. For instance, suppose that the designer modifies the flattened machine in Fig.~\ref{fig:stateMachines}(b) to produce the model in Fig.~\ref{fig:stateMachines}(c) by: 

\vspace{-0.3cm}
\begin{itemize}
\item[--] adding the new state \code{Printing}, 
\item[--] adding the transition \code{print} that associates state \code{Active} to the latter, and finally 
\item[--] modifying the source of the transition \code{done} from the state \code{Active} to the state \code{Printing}. 
\end{itemize}

\vspace{-0.3cm}
\noindent
%Then, as t
The expected transformation is clearly non-injective (as different hierarchical machines can be flattened to the same model). In addition, such a model refinement gives place to an interesting situation, i.e., more than one model is admissible (see dotted edges in Fig.~\ref{fig:stateMachines}(d)).

\vspace{-0.4cm}

\subsubsection{Implementation.}
The \emph{HSM2SM} bidirectional transformation, which relates hierarchical and flat state machines, has been implemented by means of JTL: a constraint-based model transformation language specifically tailored to support bidirectionality. It adopts a QVT-R\footnote{http://www.omg.org/spec/QVT/1.1/} like syntax and allows a declarative specification of relationships between MOF models.
The semantics is given in terms of Answer Set Programming (ASP)~\cite{GL88}, which is a form of declarative programming oriented towards difficult (primarily NP-hard) search problems and based on the stable model (answer set) semantics of logic programming.
Then, the ASP solver\footnote{http://www.dlvsystem.com/} finds and generates, in a single execution, all the possible models which are consistent with the transformation rules by a deductive process. The JTL environment has been implemented as a set of plug-ins for the Eclipse framework and mainly exploits EMF\footnote{http://www.eclipse.org/modeling/emf/}.

A fragment of the \emph{HSM2SM} transformation is illustrated in Listing~\ref{lst:HSM2SMtransfJTL}. It consists of a number of \emph{relations} defined by the two involved \emph{domains}. In particular, the following relations are reported: 

\vspace{-0.4cm}

\begin{itemize}
\item[--] \emph{Transition2Transition} which relates transitions  of the hierarchical metamodel and transitions of the flat metamodel,
\item[--] \emph{TransitionSource2TransitionSource} which relates source states of transitions of the hierarchical metamodel and the corresponding source states of transitions of the flat metamodel, and  finally
\item[--] \emph{TransitionSourceComposite2Transition\-Source} which relates source composite states of transitions of the hierarchical metamodel and correspondent source states of transitions of the flat metamodel\footnote{ The interested reader can access the full implementation at http://jtl.di.univaq.it/}.
\end{itemize}

\vspace{-0.2cm}
\noindent
The forward application of the transformation is illustrated in Fig.~\ref{fig:HSM2SMmodels}, where the model \emph{HSMm} on the left-hand side is mapped to \emph{SMm} in the right-hand side. 
%
%abovecaptionskip=-0.6cm, aboveskip=0.2cm,
\begin{lstlisting}[breaklines,style=AMMA,language=ASPencoding,mathescape,rulesepcolor=\color{black},caption={ A fragment of the HSM2SM transformation in JTL},captionpos=b, aboveskip=0.2cm, belowskip=0.5cm, label={lst:HSM2SMtransfJTL}]
transformation hsm2sm(source : HSM, target : SM) {
	...
	top relation Transition2Transition {
		enforce domain source sourceTrans: HSM::Transition{
			owningStateMachine = sourceSM: HSM::StateMachine { },
		};
		enforce domain target targetTrans: SM::Transition{
			owningStateMachine = targetSM: SM::StateMachine { },
		};
		when {...}
		where {...}
	}
	relation TransitionSource2TransitionSource {
		enforce domain source sourceTrans: HSM::Transition {
			source = sourceState : HSM::State { }
		};
		enforce domain target targetTrans: SM::Transition {
			source = targetState : SM::State { }
		};
		when {
			State2State(sourceState, targetState) and 
			sourceState.owningCompositeState.oclIsUndefined();
		}
	}
	relation TransitionSourceComposite2TransitionSource {
		enforce domain source sourceTrans: HSM::Transition {
			source = sourceState : HSM::CompositeState { }
		};
		enforce domain target targetTrans: SM::Transition {
			source = targetState : SM::State { }
		};
		when { 
			CompositeState2State(sourceState, targetState);
		}	
	}  ...        
\end{lstlisting}
\vspace{-0.4cm}

 \begin{figure}[ht]
   \center
    \includegraphics[width=8cm]{figures/xmi_a_b-new.jpg}
    \vspace{-0.4cm}
    \caption{The HSM model and the correspondent SM model}
    \vspace{-0.2cm}
      \label{fig:HSM2SMmodels}
 \end{figure}
 
  \begin{figure*}[htb]
    \center
     \includegraphics[width=12cm]{figures/xmi_c_d-new.jpg}
      \vspace{-0.3cm}
     \caption{The modified SM model and the correspondent HSM models}
      \vspace{-0.5cm}
       \label{fig:HSM2SMmodels2}
  \end{figure*}
As aforementioned the transformation is non-injective. The back propagation of the changes showed in Fig.~\ref{fig:stateMachines} therefore gives place to the following situation: the newly added transition \code{print} can be equally mapped to each of the nested states within \code{Active} as well as to the container state itself, as in Fig.~\ref{fig:stateMachines}(d). 
%Considering the \emph{HSM2SM} transformation in Listing~\ref{lst:HSM2SMtransfJTL}, the \emph{TransitionSource2TransitionSource} and \emph{TransitionSourceComposite2TransitionSour\-ce} relations are satisfied in equal way and no further condition is added in order to fix the behavior.
In particular, the modified target model \emph{SMm'} in Fig.~\ref{fig:HSM2SMmodels2}(a) is mapped back to the source models $\emph{HSMm}'_1,...,\emph{HSMm}'_4$ in Fig.~\ref{fig:HSM2SMmodels2}(b). For example, as visible in the property of the \code{print} transition, $\emph{HSMm}'_1$ represents the case in which the transition targets the composite state \code{Active}.
 
\smallskip
Such a non-determinism can still be resolved by accommodating in the transformation the prescription that any new edges in a target model should be mapped to an edge in corresponding source model, such that it \emph{always} refers to the same kind of state, e.g., the container state. This would definitely make the transformation deterministic.~However, when the solution cannot be singled out in such a general way, the decision must be left to the modeler. 
The potential information erosion have a negative impact on software cost and quality~\cite{SHL10}. Thus, designers dealing with model uncertainty need to be supported with suitable mechanism and tools in order to avoid effect of having multiple design alternatives. 

 


